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Password Encryption Key 

CLAIM OF PRIORITY 
This application claims priority under 35 USC 1 19(e) to U.S. Patent 
Application Serial No. 60/421,284 jSled on October 25, 2002, the entire contents of 
which are hereby incorporated by refereace. 

TECHNICAL FIELD 

This invention relates to eSecurity and more particularly to user 
authentication. 

BACKGROUND 

A frequently neglected aspect of the modem enterprise data storage is 
sensitive user information security. The most widespread approach used today is 
encryption of such user information as Social Security number, credit card numbers, 
e-mails, etc. with a single key and storage of the resulting encrypted data in the 
database. The logic behind such solution is that a malicious individual who gains 
access to the database will be unable to make use of the user's sensitive data because 
it is encrypted. 

Unfortunately, this approach provides a false sense of security in most cases. 
The problem is that the encryption key used to encrypt all records still needs to be 
stored somewhere in the system. For example, as soon as the system is required to 
send e-mail to the user or submit user's credit card number to llie merchant account, 
the server(s) responsible for fulfilling that requirement must use the key to decrypt 
user information retrieved from the database. Chances are that if a malicious 
individual manages to get access to the database, which is usually the most protected 
part of tihe system, he will then be able to gain access to the aforementioned server. As 
soon as this happens, such malicious individual will be able to obtain the key and 
decrypt every database record encrypted with this key. 
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SUMMARY 

A password-encrypted key (PEK) is generated from a user-supplied password, 
for example, and then used to encrypt the user's password. The encrypted password 
is stored in a user record on a server. At login, a would-be user's password is again 
5 used to make a key, which is then used to decrypt and compare the stored encrypted 
password with the would-be user's password to complete the logm. The successftd 
PEK is stored in a temporary session record and can be used to decrypt other sensitive 
user information previously encrypted and stored in the user record as well as to 
encrypt new information for storage in the user record. A public/private key system 
10 can also be used to maintain limited access for the host to certain information in the 
user record. 

According to one aspect of the invention, a secure transaction process includes 
generating a key from a user-supplied unencrypted password or other identifying data, 
encrypting the user's password with the key, creating a user record and storing the 

1 5 encrypted password in the user record. In another a^ect of the invention, upon user 
login, a key is made from a would-be user's password iising the same algorithm used 
to generate the key from the originally supplied unencrypted password, then the 
encrypted password in the corresponding user record is retrieved and decrypted using 
the key and the decrypted password and the would-be user-supplied password are 

20 compared to see if they match. 

In the preferred process, if the decrypted password and user-supplied 
password match, a temporary session record is created and the key is stored in the 
session record. In the absence of a match, the user login procedure for secure or user- 
authenticated transactions at least would preferably be aborted or terminated in some 

25 fashion. 

The key may be used to encrypt other sensitive user data, which can be stored 
in the user record. During a session in which a session record has been created, the 
key stored in the session record can be used to decrypt the other encrypted 
information stored in the user record for use in carrying out some desired action. 
30 Altematively, a public/private key pair or other asymmetric cryptography can 

be employed. A pubUc/private key pair is generated and the public key is stored on 
an application server and the mating private key only on another server, preferably a 
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secure off-site server. The original user-supplied unencrypted password is then 
. encrypted with the pubUc key and stored on the application server. Subsequently, the 
private key can be fetched from the other server and used to decrypt selected 
information on the one server, for example, for a mass mailing. A single 
5 public/private key can support the entire site. 

The password encryption key (PEK) system of the present invention 
eliminates one of the shortcomings of prior methods by using a imique encryption key 
for each user record. This key is based on at least one piece of data - user password. 
Optionally, user name (or user ID) can be used in conjxmction with user password. 
10 User*s password (and name) is obtained at each successful user login and is 
maintained by the system for the duration of that user's session. 

The details of one or more embodiments of the invention are set forth in the 
accompanying drawings and the description below. Other features, objects, and 
advantages of the invention will be apparent from the description and drawings, and 
15 from the claims. 

The details of one or more embodiments of the invention are set forth in the 
accompanying drawings and the description below. Other features, objects, and 
advantages of the invention will be 25)parent from the description and drawings, and 
from the claims. 



information. 

FIG 6 is a flowchart showing the process for safely retrieving and using stored 
sensitive information, which has been encrypted. 

FIG 7 is a flowchart showing an alternative registration process using a public 

30 key. 
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DESCRIPTION OF DRAWINGS 
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FIG 1 is a flowchart showing the user registration process. 

FIG 2 is a data stracture diagram of the user record. 

FIG 3 is a flowchart showing the user login process. 

FIG 4 is a data structure diagram of the session record. 

FIG 5 is a flowchart shoAving a process for safely storing sensitive 
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FIG 8 is a flowchart showing the process for extracting e-mail addresses using 
public/private key pairs stored in the process of FIG 7. 

Like reference symbols in the various drawings indicate like elements. 

DETAILED DESCRIPTION 

PEK integration into the system 

The PEK system is illustrated as a sequence of processes as shown in FIGS. 1, 
3, 5 and 6, running on an application server or other computer system. Preferably all 
of the processes are carried on the Intemet on a server that hosts a given appUcation 
accessed remotely by a user jSrom his or her personal computer, for example. 

1. User Registration Process (BIG. 1) 

a. User registers by, at least, providing new usemame and an arbitrary password. 

b. Generate a key from the password, (and optionally usemame/ID). A key can 
be generated by calculating an MD5 checksimi of the source data. 

c. Encrypt user password with the key obtained at step lb. Note: other sensitive 
data provided during registration (i.e. e-mail address) should also be encrypted 
with the same key. 

d. Create new user record (FIG. 2) and store usemame, encrypted password and 
otiier optional data (sensitive data encrypted) in that user record. 

2. User Login Process (FIG. 3) 

a. User logs in providing usemame/password for authentication. 

b. Cjenerate a key from the password (and optionally usemame/ED). This key 
should be identical to the key obtained at step lb. 

c. Retrieve user record by usemame and decrypt user password using the key 
obtained at step 2b. 

d. Compare the decrypted password to the one provided by user at step 2a. 

e. Reject user login if passwords do not match. Abort login process. 

f If passwords match, create a temporary user session record (FIG. 4) that will 
exist for the dxiration of the user session. (A user session is a temporary data 
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pool created after user login and destroyed as a result of explicit user logout or 
session timeout. Session timeout occurs after a certain pre-determined period 
of user inactivity.) 

g. Store resulting key in the session. 

h. Communicate session ID back to the user (client application). Session ID is a 
number or string uniquely identifying the session. Once user (client 
application) receives the session ID from the system, user will always provide 
that ID with each subsequent request for the duration of the session. This 
enables the system to get access to user session data at each request. 

3. Sensitive Information Storage (FIG. 5) 

a. User submits some sensitive data (i.e. Credit Card number). 

b. Encrypt sensitive data with a key retrieved from user's session. 

c. Store encrypted data in user's record if it is to be permanently maintained on 
the server. If it is only to be available for the session then the encrypted data 
would be stored only temporarily in the session record. 

4. Sensitive Information Retrieval (FIG. 6) 

a. User requests some system action reqiuring use of the information stored at 
step 3. (i.e. user decides to make a purchase with the credit card that he/she 
previously submitted to the system). 

b. Retrieve a key (i.e., the PEK) from the user's session record (FIG. 4). 

c. Decrypt tihie necessary data using the key obtained at step 4b. 

d. Perform the required action with decrypted data (i.e. send it to the merchant 
account) 

e. Discard decrypted data. 

Implications 

The system, at user's request, can decrypt data stored in the database at step 3 
(FIG. 5). at any time while that user's session is active. As soon as user's session 
expires, it should be impossible to decrypt this user's sensitive information without 
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knowing the user's password. Note that user's password is also encrypted at step Ic 
(FIG. 1). 

Thus, a user's sensitive data will always be as secure as the user's password in 
this system. In the majority of cases, this should be acceptable since knowledge of 
5 password only gives access to sensitive user account information ttirough the standard 
interface anyway. 

Potential Vulnerabilities and Solutions 

While PEK offers a secure way of protecting user data for users that are not 
currently logged in, in theory, it could be possible for a malicious individual to gain 

10 access to sensitive data for users that are currently logged in (i.e. have active sessions 
going). Such individual would have to obtain all of the encrypted user data and all of 
the active sessions data, extract a key &om each session, and decrypt the active user's 
sensitive data by applying extracted keys to corresponding user records. 

Logged in users, however, in most cases, represent only a small subset of all 

15 registered users and that alone greatly limits the scope of potential risks. In addition, 
the exposure can be further limited by making sure that the information linking 
session to a specific user, like usemame/ID, is not stored in session data. Instead, this 
information can be provided by the cUent application with each user's request. That 
alone would make it exceedingly difficult for a malicious individual to match a key, 

20 retrieved from any given session, to a specific user record. 

Other Considerations 

PEK makes it difficult to perform legitimate system Amotions that involve 
access to sensitive user data without an explicit user request. Bulk mailing to all 
system users is a good example. Suppose that user e-mails or at least e-mail addresses 

25 are encrypted using PEK. It will then be impossible for the system to decrypt user e- 
mails because each e-mail is encrypted wdth its owner's password and that password 
itself is also encrypted. 

One solution to this problem is to utiUze asymmetric cryptography, like PGP, 
and keep a copy of the user's password, encrypted with a public key, in the main 

30 database, as shown in FIG. 7. Only one pair of public/private keys for the entire site 
needs to be generated in advance; then the public key, used for encryption, should be 
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stored on the application server, while the private key, used for decryption, should be 
stored on an off-site secure server. This server, at the time of bulk mailing, as shown 
in FIG. 8, will decrypt user's password using that private key, generate user's PEK as 
described in step lb, and, finally, decrypt required information using PEK. The main 
advantage of this approach is that it should be possible to keep the server, which 
maintains the private key, either off-site or in a special security zone. This setup will 
ensure that while this server will be able to access the system data, the system would 
not be able to access the server. To further enhance security, this server can also be 
completely inaccessible (i.e. down) when bulk operations are not in progress. 

Another approach is to use the public key to directly encrypt only those user 
record fields that require bulk access. Distinct public/private key pairs can be used to 
encrypt different field types (i.e. e-mails and Credit Card numbers). This would allow 
for a more refined access permissions control. For example, bulk mail server will only 
have a private key that decrypts e-mails, but not Credit Card nmnbers. 

Finally, yet another approach could be to push unencrypted data to the off-site 
server at the time of its submission by user. This is the least secure approach but it 
allows the most flexibility. 

Animaber of embodiments of the invention have been described. Nevertheless, 
it will be understood that various modifications may be made without departing firom 
the spirit and scope of the invention. For example, instead of MD5 checksum, some 
other encryption algorithm or reproducible key-making methodology could be used. 
Accordingly, other embodiments are within the scope of the following claims. 
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WHAT IS CLAIMED IS: 

1 . A secure transaction process, comprising 

generating a key from a user-supplied unencrypted password, 
encrypting the user's password with the key, 
creating a user record, 

storing the encrypted password in flie user record. 

2. The process of claim 1, further comprising 

upon user login, generating a key from a would-be user's password using the same 
algorithm used to generate the key from the originally supplied unencrypted 
password, 

retrieving the corresponding user record, 

decrypting the encrypted password in the user record using the key, 
comparing the decrypted password with the would-be user-supplied password to see if 
they match. 

3 . The process of claim 2, further comprising 

if the decrypted password and user-suppUed password match, creating a temporary 
session record and storing the key in the session record, otherwise aborting the 
user login. 

4. The process of claim 3, further comprising 

encrypting other sensitive user data using the key and storing the encrypted data in the 
user record, 

during a session wherein a session record has been created, using the key stored in the 
session record to decrypt other encrypted information stored in the user record for 
use in carrying out some desired action. 

5. The process of claim 1, further comprising 
generating a pubUc/private key pair. 
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Storing the public key on an application server and the mating private key only 
another server, 

encrypting the original user-siipplied unencrypted password with the public key and 
storing the public-key encrypted password on the application server, 
fetching the private key from the oUtec server and using it to decrypt selected 
information on the one server. 

6. The process of claim 5, further wherein the other server is a secure off-site server. 

7. A secure transaction process, comprising 

generating an encryption key from user-supplied identification data, 
encrypting the user's identification data with the key, 
creating a user record, 

storing the encrypted identification data in the user record. 

8. The process of claim 7, ftirfher comprising 

upon user login, generating a key from a would-be user's identification data supplied 
at login using the same algorithm used to generate the key from the originally 
supphed unencrypted identification data, 

retrieving the corresponding user record, 

decrypting the encrypted identification data in the user record using the key, 
comparing the decrypted identification data with the would-b,e user-supplied 
identification data to see if they match. 

9. The process of claim 8, further comprising 

if the decrypted identification data and user-supplied identification data match, 
creating a temporary session record and storing the key in the session record, 
otherwise aborting the user login. 

10. The process of claim 9, further comprising 

encrypting other sensitive user data using the key and storing the encrypted data in the 
user record. 
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during a session wherein a session record has been created, using the key stored in the 
session record to decrypt other encrypted information stored in the user record for use 
in carrying out some desired action. 
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